Method and apparatus for wireless web time and expense entry via time keeping and expense tracking server access

ABSTRACT

A system and method for building GUI screens for a time keeping and expense tracking system includes a time keeping and expense tracking (TKET) server that includes computer instructions that define logic for building GUI screens according to user definitions, communication channel throughput capacity, and terminal capacity. Initially, the TKET server examines a user&#39;s ID to determine his group affiliations and ability levels for modifying the parameters, objects and layout of a GUI screen. Thereafter, the TKET server allows the user to make changes according to his defined abilities. For subsequent sessions, the TKET server builds a GUI screen according to the previously defined parameters. The TKET server is operable to act as a remote time clock. Accordingly, the TKET server is formed to receive and interpret signals that define the user ID, an account code, and whether a start or stop timekeeping event has been selected.

CROSS REFERENCE TO RELATED APPLICATION

This application is related to, incorporates by reference, and claimspriority to the filing date of the following application filed by Finch,et al.: “TIME KEEPING AND EXPENSE TRACKING SYSTEM HAVING CUSTOMIZEDGRAPHICAL USER INTERFACES”, said application having been filed on Jan.31, 2000 and having a serial number of 60/179,218. This application isrelated to and incorporates the following applications by Finch et al.being filed concurrently herewith:

1. “METHOD AND APPARATUS FOR WIRELESS WEB TIME KEEPING AND EXPENSE ENTRYWITH A CALENDAR PROGRAM/PERSONAL ORGANIZER”;

2. “METHOD AND APPARATUS FOR A WEB BASED PUNCH CLOCK/TIME CLOCK”;

3. “METHOD AND APPARATUS FOR PROVIDING FREQUENT FLYER MILES ANDINCENTIVES FOR TIMELY INTERACTION WITH A TIME RECORDS SYSTEM”;

4. “METHOD AND APPARATUS FOR PROVIDING PROMPT PAYMENT FOR TIME ENTRIESENTERED BY WAY OF A TIME RECORDS SYSTEM”;

5. “METHOD AND APPARATUS FOR MONITORING CONTRACTOR PERFORMANCE”;

6. “A TIME KEEPING AND EXPENSE TRACKING SERVER THAT GRANTS ACCESS TORECORDS BASED UPON A USER'S ATOMIC ABILITIES”;

7. “A TIME KEEPING AND EXPENSE TRACKING SERVER THAT INTERFACES WITH AUSER BASED UPON USER'S ATOMIC ABILITIES”; AND

8. “METHOD AND APPARATUS FOR UNIQUELY IDENTIFYING HARD COPY TIME SHEETFOR CROSS REFERENCE TO SYSTEM RECORDS”.

BACKGROUND

1. Technical Field

The present invention relates generally to computer based time keepingand expense tracking systems, and more particularly to such a systemthat may be customized on an entity, group, project, user or otherbasis.

2. Related Art

The tracking of workers' time has been required since workers beganworking on an hourly basis. An early example of hourly time tracking wasthe punch clock system in which a time card was assigned to each worker.Upon commencing work, the worker had his or her card punched by a clockso that the work starting time could be recorded. Then, upon ceasingwork, the worker had his or her card punched again so that the workending time could be recorded. From these starting the work ending timecould be recorded. From these starting and stopping times, a recordcould be constructed for a larger time period, e.g., a weekly period, abi-weekly period, etc. This record was then used in preparing a paycheckfor the worker and in creating other records relating to the time workedby a partial or complete work force.

While the punch clock system worked admirably in a factory environmentin which all workers worked in a single location, time keeping was moredifficult where a workforce was distributed. For example, employmentagencies specialize in placing workers in contract positions withindifferent organizations that also have their own employees. A contractemployee, while being paid by an employment agency, reports to anemployee (usually a supervisor) within the company. The contractemployee creates a time sheet based upon the work he or she performs andthen passes the time sheet to his or her supervisor at the company forapproval. When the supervisor approves the time sheet, the supervisorpasses the time sheet to the employment agency. The employment agencythen receives the time sheet and typically inputs the time sheet into acomputer that produces a paycheck for the employee and bills the companyfor the employee's time. This process is slow, tedious, prone to errorsand expensive. The cost of the overhead associated with this process mayeasily exceed twenty percent of the revenue that the employment agencyreceives for the employee.

Another difficulty relating to time keeping relates to distributed workforces. Distributed work forces are now the norm, instead of theexception, not only for employment agencies but for companies as well.In a distributed work force, employees/contractors may be distributedworldwide. Each employee/contractor is, required to submit time sheetsfor each pay period. These time sheets are received at a centralaccounting office, the time entries contained thereupon are then inputinto a computer system, paychecks are produced, reports are produced,and invoices are produced when required. While faxing or emailing timerecords to the central accounting office may expedite these operations,substantial effort must be expended in the process.

Organization of time records is another difficulty faced in timekeeping. While all employees may work for a single company, theemployees may work for different divisions, in different departments,and for different supervisors within the same department. Time recordsmust be segregated according to this organizational structure foraccounting and budget tracking purposes. Further, in an employmentagency scenario, the employment agency may service tens or hundreds ofcompanies. While each of the contractors work for, and is paid by theemployment agency, invoices must be submitted to the appropriatecompany. Further, within a particular company, a single contractor maywork on more than one project, in more than one division, and for morethan one supervisor. The contractor's time must be segregatedaccordingly when the invoice is submitted. To further complicate thiseffort, the contractor may be paid at different rates for this work,depending upon the project, division, etc. These complexities furtherincrease the difficulty in not only paying the employee but ingenerating an invoice for the company.

Expense tracking includes its own difficulties, some of which are sharedwith time tracking. Expense reports must be prepared on a periodic basisfor each member of a workforce, whether he or she is an employee orcontractor. These expense reports must be received by an accountingdepartment, allocated to the proper account, and reimbursement checksmust be prepared. With a distributed workforce, at least thosedifficulties described above apply. Proper accounting of expenses andinvoicing when required also introduces difficulties to the process. Asmay be seen, current systems do not readily facilitate time and expenseentry and monitoring for modern workforces that have employees that arecontinuously going from site to site.

Thus, there is a need in the art for a timekeeping and expense trackingsystem that overcomes the shortcomings cited above as well as othershortcomings of the prior systems.

SUMMARY OF THE INVENTION

Thus, to overcome the shortcomings of the prior systems, among othershortcomings, a timekeeping and expense tracking (“TKET”) systemconstructed according to the present invention provides a plurality ofusers with the ability to access the system via the internet and viawireless communication networks. The TKET system resides upon at leastone server computer coupled to the internet and supports access fromcomputer systems, web enabled telephones, personal data terminals, andother enabled devices including wireless personal digital assistants(PDAs). The TKET system may therefore be accessed from both wired andwireless devices. In one embodiment, users employ browser software toaccess the TKET system and require no specialized client software.

In order to support the many and varied needs of companies using theTKET system, the TKET system supports configurable graphical userinterface screens (“GUI screen”). GUI screens are those displaysprovided to users of the TKET system when the users access the TKETsystem. Via the GUI screen, the users input their time and expenserecords. The GUI screen are configurable to alter the objects presented,the layout of the objects and information presented, the color schemespresented, the timekeeping or expense tracking information required fromthe user, and in other ways that cause the TKET system to be moreeffective.

GUI screens may be customized on a company-by-company basis, adepartment-by-department basis, a group-by-group basis, aproject-by-project basis, and a user-by-user basis or upon anotherbasis. A single TKET system may be used to service the time keeping andexpense tracking needs of a plurality of companies, each of which has aplurality of divisions, a plurality of departments, a plurality ofgroups and a plurality of employees/contractors. Thus, theconfigurability of the TKET system allows differing GUI screenpresentations to be created and presented such that each group of usersis employing a different system.

GUI screen preferences for sets of users of the TKET system may beorganized in a hierarchical basis to simplify the GUI screen creationand presentation operations. In a GUI screen preference hierarchy, a toplevel of the hierarchy possesses a respective set of GUI screenpreferences that are sufficient to create a user's GUI screen. Eachlower level on the hierarchy also possesses a respective set of GUIscreen preferences. Each user serviced by the TKET system resides at aparticular location on the hierarchy. With this hierarchy positiondetermined, a GUI screen may be created for the user. In creating theGUI screen, the user's location in the hierarchy determines his abilitylevel for making changes because he inherits the GUI screen preferencesof all other higher level users in the hierarchy. However, GUI screenpreferences of successively lower levels of the hierarchy displaceconflicting GUI screen preferences of higher levels of the hierarchy.Thus, a GUI screen for a particular user of the TKET system will havehis or her GUI screen preferences determined along a top to bottomhierarchy path.

The TKET system also generates GUI screens depending upon the type ofterminal from which a user accesses the TKET system and the connectionover which the user accesses the TKET system. A GUI screen created forthe user when the user accesses the TKET system from a palm-top computeris simpler than a GUI screen created for the user when the user accessesthe TKET system from a desktop computer. Further, when the user accessesthe TKET system from a wireless device, the bandwidth of the availabledata path from the TKET system to the user's terminal will also beconsidered. A less complex GUI screen will be created and provided tothe user when lesser bandwidth is available over which to transmit theGUI screen to the user. This operating feature is particularly importantwhen the user accesses the TKET system from a wireless device.

Moreover, other aspects of the present invention will become apparentwith further reference to the drawings and specification, which follow.

BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the present invention can be obtained when thefollowing detailed description of the preferred embodiment is consideredin conjunction with the following drawings, in which:

FIG. 1 is a system diagram illustrating a multimedia electronic mailsystem constructed and operating according to the present invention.

FIG. 2 is a functional block diagram illustrating a TKET server coupledto a user terminal according to the present invention.

FIG. 3 is a functional block diagram that illustrates an expanded TKETserver system coupled to a user terminal according to one aspect of thepresent invention.

FIG. 4 is a software system configuration chart that illustrates tovarious software layers according to an embodiment of the invention.

FIG. 5 is a functional block diagram illustrating the relationshipbetween users with respect to a TKET server formed according to thepresent invention.

FIG. 6 is a chart that illustrates the hierarchical relationship betweendifferent users wherein the hierarchical relationships defined levels ofability to define the characteristics and arrangement of a GUI screenpage according to a preferred embodiment of the invention.

FIG. 7 is an exemplary display of a GUI screen according to oneembodiment of the invention.

FIG. 8 is an illustration of a series of GUI screen screens thatcollectively illustrate a concept of users having differing and relativelevels of atomic abilities for modifying the contents and arrangement ofGUI screen screens according to one embodiment of the invention.

FIG. 9 is a flow chart that illustrates a method performed by a TKETserver for setting GUI screen preferences for a user.

FIG. 10 is a flow chart illustrating a method for generating a GUIscreen page to a user and for receiving data inputs from the user forstoring and processing.

FIG. 11 is a functional block diagram illustrating a TKET server incommunication with a user terminal according to an alternativeembodiment of the invention.

FIG. 12 is a table illustrating a method within a TKET server forgenerating a GUI screen display at a remote terminal according to apreferred embodiment of the invention.

FIG. 13 is a table determining whether to generate a set of signals fordisplaying either a full, reduced or minimal GUI screen display basedupon communication path characteristics according to one aspect of thepresent invention.

FIG. 14 is a functional block diagram illustrating the circuitry withina time keeping and expense entry server according to one embodiment ofthe present invention.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 is a system diagram illustrating a time keeping and expensetracking (TKET) system 100 constructed and operating according to thepresent invention. A TKET server 102 couples to the internet 104 (WorldWide Web) and converses with all other devices using one or more packetswitched protocols supported by the internet 104. A telephone network106 (which may be the public switched telephone network (“PSTN”) oranother telephone network couples to the internet 104 via a gateway 108.Further, a wireless network 110 couples to the internet 104 via agateway 112. The manner in which the internet 104 (or other packetswitched networks) couples to the telephone network 106 and to thewireless network 110 is generally known. Thus, the interaction betweenthe internet 104 and the other networks 106 and 110 will be describedonly as it relates to the present invention. And, of course, thestructure illustrated in FIG. 1 is an example structure. Otherstructures may be constructed and operate according to the presentinvention to support time keeping and expense tracking operations.

Computers 114 and 116 couple to the internet 104 and may interact withthe TKET server 102 through this connection. While computer 114 has adirect connection to the internet 104, computer 116 must access theinternet via an internet Service Provider (ISP) 118. Many userscurrently access the internet via an ISP, as illustrated with theconnection for computer 116. However, some computers currently accessthe internet via an Intranet or other coupling network. In thisconstruction, an ISP may not be required. Further direct connections tothe internet are already possible such as shown with computer 114. Thus,simply stated, the structure illustrated in FIG. 1 provides a platformof operation for the present invention but must not be constructed tolimit the teachings of the present invention.

Web-enabled telephones 124 and 126 couple to the telephone network 106.These telephones 124 and 126 each have displays upon which a GUI screenmay be presented to the user. The telephone network 124, as waspreviously described, may be the PSTN, which transmits data in a PCMformat. In another embodiment, the telephone network 124 may be a packetswitched network that supports packet-based communications. Theteachings of the present invention, therefore, apply equally well tocurrent or future telephone network technology.

Wireless devices 120, 121 and 122 wirelessly connect to the wirelessnetwork 110. The wireless network 110 may be cellular based, satellitebased or otherwise structured to provide wireless communication servicewithin a service area. Wireless device 122 is a portable computer thatservices communications over a wireless link to the wireless network110. Wireless devices 120 and 121 are personal data assistants thatwirelessly communicate with the wireless network 110. The wirelessnetwork 110 communicates with the internet 104 via the gateway 112.

A local area network/wide area network (LAN/WAN) 128 couples to theinternet 104 via a firewall 130. At least one computer terminal, e.g.,computer 132, couples to the LAN/WAN and may communicate with the TKETserver 102 via the LAN/WAN 128 and the internet 128. The LAN/WAN may besupported by a company, a service provider or another organization.

The TKET server 102 may be operated by a single company or a pluralityof companies that use the TKET server 102 to support itstimekeeping/expenses. Alternately, the TKET server 102 may be operatedby an application service provider (ASP) that sells timekeeping andexpense services to a plurality of customers. The timekeeping servicesprovided by the ASP may be bundled with other services so that the ASPprovides a suite of services to its customers.

According to the present invention, a plurality of users accesses theTKET server 102 via differing communication paths and using differingterminal devices. Time and expense information is uploaded from theterminal devices to the TKET server 102 where it is stored and laterused to generate invoices, paychecks, reports, and other alternaterecords. Because the TKET server 102 is accessible from any locationhaving internet 104 access, the TKET server 102 provides ubiquitousservice worldwide. Thus, the TKET server 102 as easily servicesdistributed workforces as it does centralized work forces. For exampleusers at terminal devices 120, 132 126 and 116 may work for a singleemployer/contractor at differing physical locations. However, inreporting time and expense information, they simply access the TKETserver 102 via respective network connections.

A single user may use multiple and differing terminal devices to accessthe TKET server 102. Because of this, the user is not precluded fromentering his or her time from a single terminal device. While the useris traveling, he or she may use a portable computer 122 or personal dataassistant 121 to enter time. However, while working or at home, the usermay use his or her personal computer 114 to enter time and expenseinformation. Thus, as compared to prior timekeeping/expense systems, theTKET server 102 provides a centralized service environment that is notlimited by the users' equipment.

The design of the present invention is particularly advantageous in thatit allows an employer to monitor time keeping and expense tracking in areal-time manner. Stated differently, by requiring an employee to accessthe system to enter his start and stop ties, the system serves as a timeclock. Moreover, the system includes the flexibility of allowing anemployee (user) to enter previously worked by unentered time. Forexample, an employee may need to enter travel time.

With respect to the time clock feature of the invention, a GUI screenfor a user of a wireless PDA terminal 121, for example, may haveseparate objects for start and stop times. Thus, the PDA may beprogrammed to establish a connection with the TKET server and toautomatically upload a start or stop time when so requested by the user.With the present system, a PDA may serve as a portable time clock forthe user to help him track his time.

Continuing to refer to FIG. 1, TKET server 102 generates communicationsignals 134 that are to be delivered to any one of the plurality ofterminals shown in FIG. 1. The communication signals 134 are created ina form to trigger terminal user software to generate displays containinginformation defined within communication signals 134. For example,communication signals 134 may include signals in a form that trigger andthat can be used by a plurality from terminal software to create a GUIscreen. The form of the communication signals 134 and the contenttherein directly affect the display at the receiving terminal. Forexample, communication signals 134 actually comprise a large number ofsignals or information that result in a specified GUI screen beingdisplayed on the terminal display. Thus, either for a terminal having alimited capacity for receiving and handling large amounts of informationor for a network path having low bandwidth data throughput capacity, themagnitude or total amount of signals that comprise communication signals134 will be reduced thereby resulting in the display of a reduced GUIscreen page. In the case, by way of example, of a mobile terminal, thesignals within communication signals 134 may be so limited that littlemore than text is transmitted to the terminal.

The communication signals 134 also include control information to promptthe receiving terminal to generate a response indicating a userselection of options or questions asked within the GUI screen for theresponse signals 136 are received by TKET server 102.

For most user terminals, the response signals 136 use the hypertexttransfer protocol (HTTP) that is used by web servers and client browsersto communicate over the World Wide Web. Generally, the protocol is usedfor moving documents around the internet. Additionally, terminalsusually employ hypertext mark-up language (HTML) for creating World WideWeb pages. Accordingly, the TKET server 102 can estimate thecapabilities of the terminal, and perhaps the transmission data pathfrom the HTTP and HTML information that is received as a part ofresponse signals 136. As will be explained in greater detail herein thisapplication, TKET server 102 determines the characteristics of the GUIscreen display that are to be created at the user terminal according tothe content of response signals 136. In addition to the HTTP and HTMLinformation from which TKET server 102 may infer terminal orcommunication path capabilities, an actual synchronized addressselection by the user to which response signals 136 are being routed maybe used, in an alternate embodiment, by the TKET server 102 indetermining GUI screen display characteristics. Alternatively, responsesignals 136 may merely include an indication of a user selection fromwhich a corresponding GUI screen display is generated.

Other factors are also used by TKET server 102 to determine what GUIscreen display signal characteristics are appropriate. By way ofexample, the TKET server 102 is operable to determine the number ofgateways in the transmission path between it and the user terminal fromexamining the http information associated with a received signal. Forexample, the network of FIG. 1, a Gateway 108 is shown to exist in thepath between TKET server 102 and telephones 124 and 126 of telephonenetwork 106. Between TKET server 102 and user terminal 122, there notonly exists a Gateway 112, but also a wireless network 110 thatintroduces substantial propagation delays. Accordingly, by determininghow many Gateways exist in the path and other characteristics of thepath such as whether the communication signals are being routed througha telephone network 106, a local area or wide are network 128, or awireless network 110, as well as the number of Gateways through whichcommunication link passes, TKET server 102 is able to determine anapproximate value for through put capacity. For example, merely havingto go through a wireless network 110 might, in the described embodiment,result in TKET server 102 transmitting, at most, a reduced set ofdisplay signals for forming a reduced GUI screen display.

FIG. 2 is a functional block diagram illustrating a TKET server coupledto a user terminal according to the present invention. A user terminal204 communicates with TKET server 208 by way of interface 212. Interface212 may comprise any combination of an ISP, a gateway and an internet, awireless network, a PSTN or any other communication network. TKET server208 also is coupled to database 216 that is for storing user informationincluding user selected GUI screen display parameters.

TKET server 208 comprises a session interface module 220, a GUI screendefinition module 224 and a GUI screen display module 228. Each of thesemodules operates in concert to support the disclosed invention herein.To illustrate, GUI screen definition module 224 is for storing defaultGUI screen page parameters and GUI screen display definition informationfor creating GUI screen pages on a user terminal display. Additionally,module 224 includes information for defining logic for rearranging,renaming, adding, and deleting time entry or expense trackingcomponents. The specific logic contained therein is better explained inthe discussion of the figures that detail operation of the invention.

The inventive system is operable to enable a user to customize the GUIscreen displays to a degree not seen in other display systems, and moreparticularly, in time and expense tracking systems. To enable the userto select display parameters, the inventive system includes a GUI screendisplay module 208 that creates GUI screen displays according to thedefinition information stored in GUI screen definition module 224.Additionally, GUI screen display module includes logic for creatingdisplays according to the display parameters selected by the user thatare stored within database 216.

Database 216 is for storing customized display parameters selected by auser. For example, the number, arrangement and names of elements withinthe rows and columns of a GUI screen display page on a per user basisare stored within database 216. In the preferred embodiment of theinvention, database 216 is for storing multiple display pages for eachuser that requires multiple pages.

By way of example, a user may want to define multiple GUI screen pagesfor display on his terminal screen according to the terminal type. Ifthe user, for example, typically accesses his time and expense trackingsystem either with a PDA or with a desktop computer terminal, hisdisplay capabilities will vary according to the capacity of the terminalin terms of bandwidth, memory, and display processing throughputcapacity. Accordingly, database 216 is formed to include softwareinstructions and memory capacity to store multiple GUI screen displaypages according to user need and GUI screen display module 208 is formedto include logic for selecting between the multiple GUI screen pages.

In addition to database 216 that stores multiple display pages for eachuser, session interface module 220 is for determining the terminal typethrough which the user is accessing the TKET server 208. Morespecifically, session interface module 220 includes softwareinstructions that define logic for determining the bandwidth andterminal type of the user terminal. The session interface module 220, inone embodiment, produces a GUI screen selector signal for the GUI screendisplay module 228 to determine what GUI screen display is to be createdfor the user terminal 204 the GUI screen selector signal.

There are many different ways in which the session interface module 220may determine the user terminal type. In one embodiment of theinvention, the user specifies his terminal type by selecting acorresponding URL when accessing the TKET server 208. By way of example,the user is instructed to use a first URL for accessing the TKET 208when the system is being accessed with a PDA and a second URL when thesystem is being accessed with a desktop or laptop computer.

In another embodiment of the invention, a terminal ID is transmitted tothe TKET server 208 that identifies the terminal type. For thisembodiment, session interface module examines the contents of adatabase, e.g., database 216, to determine the terminal type based uponthe terminal ID. In yet another embodiment of the invention, the user isgiven an option to select from one of several GUI screen display modes.For example, the user may be given the option to select either FULL orREDUCED wherein the display modes relate to the capacity of the userdisplay terminal.

As another aspect of the invention, the session interface ID moduleexamines the signal path through which the GUI screen page is to bedelivered to the user terminal. For example, if the signal path includesa wireless branch, it may determine to transmit a GUI screen page thatwould have a smaller memory or data transport capacity requirement.

In yet another embodiment of the present invention, the sessioninterface module transmits a signal to the user terminal to measure aresponse time. The GUI screen display module then selects GUI screendisplay page types according to the response time. For this embodiment,it is assumed that a response time corresponds to a network datatransport capacity. Accordingly, a GUI screen page requiring thetransmission of lesser amounts of data is selected for those networkpaths whose transport speed is lower.

In operation, a user connects to TKET server 208 with his terminal 204to enter or review time and/or expense information. Session interfacemodule 220 determines the user terminal type, if necessary, by sending amessage to the user to prompt the user to select a GUI screen displaypage type or mode. The GUI screen display module then builds andtransmits a GUI screen display page based upon the GUI screen selectorsignal value created by the session interface module 220 and based uponthe user specific GUI screen page information stored within database216.

The above described embodiment includes having multiple GUI screen pagesfor each user, if necessary. In an alternate embodiment, each userdefines only one GUI screen page. The parameters of the page includegraphical information including unique fonts, color patterns, graphicalsymbols and related spacing and layout of all of these GUI screen pageelements and aspects. If, however, the GUI screen selector signalindicates that the user terminal has a reduced data capacity in terms ofprocessing speed or memory, the GUI screen display module builds a GUIscreen display page that omits certain elements of the page. Forexample, if the user terminal type is a PDA having only black and whilecolor capability, the GUI screen display module would build a GUI screenpage without color information. Additionally, the GUI screen displaymodule may build a GUI screen page that omits certain graphical signals.Thus, for this embodiment, the GUI screen page is said to be “implied”from the stored GUI screen page.

In yet another alternate embodiment of the invention, the GUI screendisplay module builds an implied page based upon on of several differentuser created GUI screen pages stored within database 216. For example,if the GUI screen selector signal indicates that the smaller (in memorysize) of the two GUI screen pages is to be built for transmission to theuser terminal, the GUI screen display module may still build a GUIscreen page whose elements are implied from the selected GUI screenpage. To illustrate, the user may have selected a smaller GUI screenpage, but based upon the user terminal type, the amount of informationof the smaller GUI screen page may still exceed the capacity of the userterminal. For example, if the user terminal is a cellular device havinglimited display and data processing capability, the GUI screen page maybe reduced to being little more that a string of alphanumericcharacters.

FIG. 3 is a functional block diagram that illustrates an expanded TKETserver system coupled to a user terminal according to one aspect of thepresent invention. The system of FIG. 3 is similar to that shown in FIG.2 except that the TKET server of FIG. 2 is replaced by a network of TKETservers. Primarily, the network of TKET servers shown generally at 300illustrate that the components (individual TKET servers) of the TKETserver network are coupled to communicate with each other to produce ascaleable TKET server network that can be formed to satisfy systemrequirements. As may also be seen, the TKET server network comprisesapplication servers that are coupled to the users through a plurality ofweb servers.

FIG. 4 is a software system configuration chart that illustrates tovarious software layers according to an embodiment of the invention.More specifically, the chart of FIG. 4 illustrates relative arrangementand Each layer represents different levels of abstraction with respectto the software and its functionality in a TKET server.

The lowest level layer is the database interface layer 410. Databaseinterface layer 410, as its name implied, is the layer at which computerinstructions cause a TKET SERVER processor to interact with a databasewithin a storage device to obtain specific user selected GUI screendisplay parameters as well as stored user data. The second layer is thecoarse object layer 420. The course object layer 420 is the layer atwhich the programmer can access a whole table of objects as one object.

The third layer is the fine object layer 430. The fine object layer isthe layer at which single objects represent one user, one project, orone such other object in the system. The fourth layer is thepresentation layer 440. A presentation layer is a layer at which HTML,WAP or HDML is prepared for the user and user input is passed back tothe program. For example, the computer instructions at the presentationlayer are those instructions that prompt a processor to generate theappropriate type of GUI screen. The fifth layer is the common gateinterface (CGI) script layer 450. CGI layer 450 is the layer at whichpresentation data is passed up to the web server.

FIG. 5 is a functional block diagram illustrating the relationshipbetween users with respect to a TKET server formed according to thepresent invention. TKET SERVER 504, an application server, is coupled tocommunicate with a plurality of users by way of a communication network.A user terminal 504 is coupled to communicate with TKET server 504 andto receive GUI screen displays therefrom. Additionally, user terminals512 and 516 are coupled to communicate with TKET server 504. Dashedlines 520 and 524 are shown between user terminal 504 and user terminals508 and 512 to illustrate a business relationship between the users ofthe respective user terminals. By way of example, if the user of userterminal 504 desires to establish a time management and tracking serviceand to establish a service relationship with the Operator of TKET server504, then the user of user terminal 504 is, for the purpose of thisexample, the administrator for the time management and tracking company.Thus, the users of terminals 512 and 516 are the clients of the user ofterminal 504.

In the illustration of FIG. 5, there also exists a business relationshipbetween the users of terminals 512 and 516. For simplicity, anillustration of the business relationship between user terminals 528 and532 and user terminal 516 is shown. User terminal 512, has businessrelationships with other lower ability users that are not shown herein.

One reason that the business relationships are indicated in FIG. 5 forexemplary purposes is to illustrate why each layer of users hasdifferent ability levels. Thus, for example, user 508 may be anadministrator for the time keeping and expense tracking functionsubscribed or used by each of the lower ability level users 512, 516,528 and 532 and supported by the operator of TKET server 504. Similarly,users 512 and 516 may be managers for the time keeping and expensetracking function. Users 528 and 532 may be mere users. Alternatively,they too may be managers having yet lower ability level users. Forexample, if each of the users 528 and 532 represent a company, eachcompany may have organizational units such as section, departments, ordivisions that are lower ability level users. A better understanding ofthe abilities of the different level users is explained in thediscussion relating to FIG. 8.

FIG. 6 is a chart that illustrates the hierarchical relationship betweendifferent users wherein the hierarchical relationships defined levels ofability to define the characteristics and arrangement of a GUI screenpage according to a preferred embodiment of the invention. The chart ofFIG. 6 illustrates the relationship of three hierarchical ability levelsof users. The first hierarchical level shown generally at 604 representsan application service provider (ASP) that also serves as anadministrator for the example shown herein. The administrator originallyreceives a GUI screen page that is set up according to a plurality ofdefault settings. Being administrator, however, the objects of the GUIscreen page may readily be modified by the ASP/Administrator.

The second hierarchical level shown generally at 608 includes five users612, 616, 620, 624 and 628, each of which may have additional lowerlevel users as shown at hierarchical level 632. For example, user 628further includes four lower ability level users 636, 640, 644 and 648.While not shown specifically herein FIG. 6, each of the users of level632 may also have additional lower levels users. For example, if eachuser of level 632 represents a different company, there may still existsseveral lower layers according to the size of the company and the numberand arrangements of the divisions of the company.

Continuing to refer to FIG. 6, each level of user receives a GUI screenpage having a default arrangement and object labels and contents.According to the selections of all of the users above the present userin terms of what may or may not be modified, the present user may modifythe arrangement and label values and well as content of the rows,columns and objects of the GUI screen page. A better explanation of therelative abilities of users is explained in the discussion of FIG. 8below.

In general, however, each user receives a GUI screen page having adefault set of values that is determined by the higher level of users.Thus, the ASP/Administrator of group 604 has a first set of defaultvalues. The users of group 608 receive GUI screen pages whose defaultsettings are determined by the ASP/Administrator 604. Similarly, thelower level users of group 632 receive GUI screen pages whose defaultvalues are determined by the ASP/Administrator and by the higher leveluser of group 608 to which the user of group 632 belongs. For example,user 628 and ASP/Administrator 604 determine the default settings ofusers 636, 640, 644 and 648. In general, each hierarchical level of FIG.6 has a different set of GUI screen default settings according to therelative placement of the user.

While the table of FIG. 6 illustrates only three levels of users, it isunderstood that there may be additional levels below the third levelshown generally at 632. While there may not be any higher levels thanshown in FIG. 6, it generally is possible to have additional levels ineither direction if the highest level shown is not the ASP as is thecase in FIG. 6.

The hierarchical relationship between the users affects more than screendefinitions. More specifically, access control lists may be defined thatspecify access to specified information or lists of information.Generally, each user may transparently view the GUI screen screens ofall lower level users. If a user belongs to multiple groups, forexample, wherein there are a plurality of lower level users within eachgroup, the user will have the ability to transparently review or even tomodify the content of the GUI screens of the lower level users in eachgroup. Each of the lower level users, however, can only review the GUIscreen pages of their lower level users. They may not review the GUIscreen pages of users at the same or at higher hierarchical levels. Insuch a case, the user is “hidden” from those users whose screens hecannot access.

Moreover, because project codes are similar to expense accounts, it isoften desirable to prevent the project codes from being viewed by lowerlevel users in a selective manner. Thus, a user, e.g., a manager leveluser, may select what codes may be viewed by the users in a given groupthrough the access control lists. If a lower level user also acts as amanager for his lower level users, the upper level manager will haveaccess to view the codes and access control lists defined and controlledby the lower level manager.

The function of hiding project codes may also be performed on a per userbasis through the use of the access control lists. Thus, a manager mayspecify in an access control list those lower level users that haveaccess to a given code.

FIG. 7 is an exemplary display of a GUI screen according to oneembodiment of the invention. The screen of FIG. 7 includes five groupsof information 702, 704, 708, 712 and 716. As has been discussed above,different users have different ability levels in terms of the extent towhich they may make selections for the characteristics of a GUI screen.The example of FIG. 7 illustrates a screen that is observed by a usernot having the highest ability level. Thus, the screen received by theuser of the screen of FIG. 7 includes groups 702, 704 and 708 whoseobjects are not modifiable. By way of example, group 702 includes anobject reserved for displaying a corporate logo while group 704 includesan object of displaying a corporate name. Group 708 includes at leastone object that includes departmental identifiers. Similarly, group 716includes an object for displaying a banner or advertisement that may notbe modified by the u user of the screen illustrated in FIG. 7.

The objects of group 712, however, are modifiable by the user of thescreen shown in FIG. 7. For the example herein, the objects of group 712are for storing the actual time or expense entries. Moreover, the actualarrangement of the columns and rows of group 712 are modifiable. Thus,based upon user selection, rows may be displayed as columns or viceversa. Additionally, the actual names given to these rows or columns aremodifiable. In the preferred embodiment of the invention, the screen isinitially received by the user with a set of default names and values.Then, for each row or column, the user may activate a pull down menu toselect from one of a group of alternate names. In an alternativeembodiment of the invention, the user may also type in a name if one ofthe alternative names does satisfy the user's requirements. For example,a row labeled as “entertainment” may have alternate names including“dining”, “alcohol”, or “sporting events”. In the alternate embodimentof the invention, the user may choose to type a label that does notexist such as “Golfing Fees” if, for example, the user entertainsclients on the golf courses.

The TKET server 700 supports fully customizable GUI screens, which arethe presentation, made to the user when requesting time entries and/orexpense information. Each time entry typically includes at least fivecomponents: (1) an identity, e.g., the user's identity; (2) acorresponding date or date range for the time entry; (3) the duration oftime for the time entry, or alternately starting and stopping times forthe time entry; (4) elements of the time entry, e.g., project code,project sub-code(s), time categories and subcategories, etc., and (5)comments regarding the time entry. In the described embodiment, even thename, size and arrangement of the comments field (object) isconfigurable by the user. As may be seen from examining group 712 inFIG. 7, the top row of object titles represent the default settings thatare provided by a higher level user while the dashed objects below thetop row of object titles represent, more generally, that a pull downmenu may used to allow the user to select from a list of object namesfor each object.

The chart of FIG. 7 illustrates, therefore, a time entry GUI screensession for an employee having the lowest ability level/role fordefining the screen display parameters. The objects of group 712 may bearranged by the user in any order or may even be renamed by the user.

FIG. 8 is an illustration of a series of GUI screens that collectivelyillustrate a concept of users having differing and relative levels ofatomic abilities for modifying the contents and arrangement of GUIscreen screens according to one embodiment of the invention. Referringnow to FIG. 8, each of the three GUI screens contains five rows and onecolumn of objects. In the first GUI screen 810, it may be seen that allfive objects 811 through 815 are highlighted (as indicated by the boxaround the object) to indicate that each of the objects may be modified.The GUI screen of FIG. 8 is one that is under the control of a TKEKserver administrator having the highest level of ability to modify theobjects within the screen. Accordingly, all five objects are modifiableby the user (administrator).

The screen shown at 820 shows the same five objects 511 through 815 ofscreen 810 but that only objects 812 through 815 are highlighted. Thatobject 811 is not highlighted indicates that the user of screen 820 hasa lower ability level and, more specifically, cannot modify the displayor content of object 811. In general, if object 811 represents a valueor symbol that the administrator does not want its lower level users tomodify, then the contents of that object appear for all of the lowerability level users.

The screen shown at 830 also includes the same five objects but onlyobjects 813 through 815 are highlighted illustrating that the user ofscreen 830 may not modify objects 811 and 812. While object 811 was madeun-modifiable for both of the lower ability users of screens 820 and830, the user of screen 820 made object 812 un-modifiable for the userof screen 830. While not explicitly shown in FIG. 8, it should beunderstood that there might well be additional screens that representadditional lower ability users. For example, the user of screen 830 mayrepresent a company. In such a case, each of the lower ability screenswould relate to organizational units of the company. No particular limitas to the number of ability levels is intended by the illustration ofFIG. 8, which includes only three ability levels.

Continuing to refer to FIG. 8, it may be seen that a reporter 840 iscoupled to receive each of the GUI screens 810, 820 and 830 from theuser terminals displaying them. A reporter may be any type of devicethat is for storing or displaying information of the type beingsupported on each of the GUI screens. By way of example, if the systemof FIG. 8 relates to time entry, the reporter may be a terminal andscreen of a supervisor that is monitoring the time entries of each ofthe users of the three GUI screens 810, 820 and 830. Alternatively, thereporter may be a report generating routine stored within TKET server102 (of FIG. 1, for example) and executed by a processor within TKETserver 102.

While the example of FIG. 8 includes an illustration of how objects maybe changed, it is to be understood that a user also may be allowed by ahigher ability level user (e.g., a manager or an administrator) tochange other features of the GUI screen including color, font type, etc.Moreover, as mentioned before with respect to FIG. 7, even the lowestability level user has the capacity to rename objects. Thus, for areporter 840 to be able to meaningfully monitor the time keeping andexpense tracking of the user, a database or table is needed to map thechanges made by the user from the default settings provided to him.

The database or table thus enables the reporter to analyze numbers andadd values from different users having different names but representingthe same basic parameter. For example, one user may track a term named“Hourly value” while another user tracks a term name “Client cost”wherein both numbers represent the amount that the client or project isto be charged for the contract employees time and effort. Thus, if themapping of object names is found within database 216 of FIG. 2, forexample, reporter 840 must communicate with database 216 to properlygenerate the time and expense tracking reports.

FIG. 9 is a flow chart that illustrates a method performed by a TKETserver for setting GUI screen preferences for a user. First, the TKETserver receives and establishes a connection with a user and determinesthe user ID (step 904). As was shown in FIG. 1, the connection maycomprise a path through any one of the public switched telephonenetworks, through a wireless network, through a local area network,through any one of the various internets or through any combination ofthese networks.

After the connections is established, the TKET server determines theuser's role and associated abilities for defining and modifying objectsof a GUI screen (step 908). For example, if the user role is that of anadministrator, the TKET may allow the user to make any change from anoriginal default screen that is desired (unless, of course, the TKETserver operator chooses to make one or more objects fixed (e.g., a smalllogo inconspicuously displayed). Alternatively if the user is a lowerability level user relative to the administrator, then the TKET servermust determine the objects that the user is allowed to modify or change.

Once the TKET server determines the user role and correspondingabilities, it provides the options to the user for making changes to theGUI screen page (step 912). As indicated before, these options areoptions for modifying GUI screen display parameters of a default page.In an alternate embodiment, however, a default page is not provided forthe highest ability level user. For this embodiment, the highest leveluser (administrator) must define the layout of the GUI screen page. Thedefault page of course is the page settings created by a user that isone ability level higher than the present user and includes theselections of all users that are at a higher ability level than thepresent user. In the case of the highest ability level user (e.g., anadministrator), the GUI screen default page is created by the operatorof the TKET server for the purpose of providing the administrator astarting point for creating and defining his GUI screen page.

Thereafter, the TKET server receives the user's GUI screen pagedefinitions (step 916). The definitions can be in the form of fixed datavalues, text (e.g., formulas for making calculations that are to bedisplayed), and row and column names, row and column arrangements.

After each GUI screen definition is received, the invention includesaccepting and modifying the GUI screen definitions from the defaultvalue(s) (step 920). This step includes storing the received GUI screendefinitions with respect to the user ID. After each GUI screendefinition is received, the invention includes determining whether theuser is through making changes and defining his GUI screen or whether topresent the GUI screen modification options to the user once again toreceive more changes (step 924). For example, the TKET server maytransmit a signal asking the user if he has more changes to make. Basedupon the response, either step 912 is repeated or the inventive methodof FIG. 9 is complete.

Each of the above steps for creating a GUI screen page may be performedmultiple times to create multiple GUI screen pages. For example, a userrealizing that he will want to access the GUI screen page from twodifferent terminals, each having significantly different data handlingcapacity, may want to define a GUI screen page for each of the twoterminals. Accordingly, when the user logs into the GUI screen server,he is able to select the desired GUI screen page.

FIG. 10 is a flow chart illustrating a method for generating a GUIscreen page to a user and for receiving data inputs from the user forstoring and processing. Initially, when the user logs in, the TKETserver examines the user ID so that it may determine the necessaryinformation for generating a GUI screen page to the user (step 1004).Thereafter, the TKET server determines the group IDs and membershipsthat correspond to the user ID received from the user (step 1008).

As a part of determining how to set up a GUI screen page, the inventionincludes determining what type of communication channel is to be used totransmit the created GUI screen page (step 1012). For example, this stepincludes determining whether the GUI screen page is to be transmittedvia wireless data link, through a low bandwidth serial line by way of amodem such as a typical 56K byte/sec desktop computer modem, or throughhigh speed serial digital communication link utilizing a T1 or T3 line.More generally, this step includes determining the data throughputcapacity of the data link for slowest known data link between the userterminal and the TKET server. Knowing the data throughput capacity bydetermining the type of communication channel is important fordetermining what features to include in the page for transmission to theuser. One part of determining data throughput capacity of the data linkis determining what the appropriate protocol for generating andtransmitting the page should be. For example, hypertext markup language(HTML) is appropriate for a full GUI screen page being transmitted to adesktop terminal. Similarly, hand held device markup language isappropriate for PDAs and other hand held devices while wirelessapplication protocol (WAP) is appropriate of wireless devices orterminals.

Finally, in order to determine the characteristics of the GUI screenpage that is to be created, the TKET determines the terminal type (step1016). For example, if the terminal type is a PDA, its capacity forreceiving GUI screen displays having color information will likely benotably lower than the capacity of a desktop computer. Similarly, if thePDA is to receive the GUI screen page over a wireless link, then theamount of information that may be transmitted must be reduced evenfurther. Accordingly, a simpler GUI screen page should be created.

In addition to the above steps of analyzing the system parameters thataffect how much information may be used to form a GUI screen page fortransmission to the terminal, the inventive method includes determiningwhat user profiles have been previously defined for the user. Thus, theinvention includes obtaining the user profiles that, in the preferredembodiment, are stored in a database and may be accessed by the user ID(step 1020). Additionally, besides determining what the defined objectsare for the user and how they should be arranged on a GUI screen page,the data content of the objects must be retrieved so that the GUI screenpage may be populated with the user's data (step 1024).

At this point, the TKET server has determined the necessary informationfor building the GUI screen page. Thus, the next steps include buildingthe GUI screen page (step 1028), transmitting it to the user (step1032), receiving data entries from the user for some of the variousobjects of the GUI screen page (step 1036), and storing the data in adatabase (step 1040).

The above listed method steps for creating a GUI screen page accordingto network and user selected parameters may be practiced in one ofseveral different manners. For example, in the described embodiment, theTKET server determines the type of GUI screen page that should be builtfor transmission to the user based upon transmission channel andterminal capacities. For this embodiment, the TKET server analyzes auser terminal ID to determine type of terminal. The user ID may beselected and entered by the user or it may be embedded in a set of setupsignals transmitted by the terminal.

With respect to the transmission channel, TKET server analyzes thesource of the incoming communication link. By way of example, if thecommunication link is received by the TKET server from a mobileswitching center of a wireless network, then the TKET server determinesthat a wireless communication link is included in the communicationpath. In the described embodiment, the TKET server maintains a list ofprefix numbers that identify the mobile switching centers. The list ofnumbers and their originating sources may be operated in a mannersimilar a telecommunication network service control point.

In an alternate embodiment of the invention, the first time a userestablishes a link to a TKET server for a session, the server merelysends a signal to the terminal to prompt it to generate an immediateresponse in order to measure a response time. By measuring the responsetime, the TKET server is able to roughly determine data transportcapacity through the established communication link for that session.Accordingly, it is at least partially from this approximation that theTKET server selects the size and complexity of the GUI screen page thatit builds for transmission to the user terminal.

In yet another embodiment of the invention, the TKET server initiallyselects one of a plurality GUI screen formats according to terminaltype. Thereafter, GUI screen elements are implied according to thecommunication channel performance. For example, if the select GUI screenthat corresponds to terminal type includes color information, but thecommunication channel response time does not allow for color informationto be transmitted without incurring a delay beyond a specified amount,the TKET server may create an implied GUI screen that does not includecolor information. Thus, as may be seen, the invention includesdetermining the complexity of the GUI screen that is to be built notonly by operator selection, but also by system capabilities orperformance.

The actual parameters that are to be selected or discarded for thoseembodiments in which a full set of GUI screen display signals is not tob e generated by the TKET server makes the determination may readily bemodified according to implementation of the inventive methods herein. Ingeneral however, they include decisions about whether to transmit colorinformation, whether to transmit graphical symbols, logos and designs oreven font information, whether to transmit specified advertisements, andwhether to transmit certain arrangement information.

FIG. 11 is a functional block diagram illustrating a TKET server incommunication with a user terminal according to an alternate embodimentof the invention. Referring now to FIG. 11, it may be seen that a TKETserver 1100 is in communication with a user terminal having a displayscreen 1104. As may be seen from viewing screen 1104, three URLsrepresenting different display options from which the user may chooseare being displayed. Each display option represents different displaynodes. First, option 1108 labeled “Full” is for enabling the user toselect a full GUI screen display node. Option 1112 is for enabling theuser to select a reduced GUI screen display while option 1116 is forallowing the user to select a minimum display. The user selection isthen transmitted by the user terminal in a user selection signal 1120that is transmitted to TKET server 1100. A display module 1124 withinTKET server 1100 is operable to receive signal 1120 and to generatedisplay signals to create a GUI screen display responsive thereto.

While the example of FIG. 11 illustrates the user being given URLs toselect GUI screen display signal characteristics being transmitted bythe TKET server, other approaches may be employed. More specifically,the URLs are used to cause the communication link to establish acommunication link to an internet address. The TKET server, utilizesgenerates GUI screen display signals having characteristics thatcorrespond to the URL. Thus, for the example of FIG. 11, because threeURL addresses are shown, the TKET server has at least three differentsets of URL signal display characteristics to generate responsivethereto. In an alternate embodiment of the invention, however, a GUIscreen display may prompt the user to select from a plurality of displaycharacteristics. The user choice is then transmitted to the TKET serverfor it to generate GUI screen display signals having characteristicsthat are responsive thereto.

In one embodiment of the invention, each of the options presented to theuser on screen 1104 is one that triggers a different URL, which causessignal 1120 to be transmitted to different destinations. In anotherembodiment of the invention, each of the choices is merely identifiedand reflected within signal 1120. Accordingly, display module 1124extracts the selected choice from signal 1120 and generates the displaysignals to create a GUI screen that is responsive thereto.

FIG. 12 is a table illustrating a method within a TKET server forgenerating a GUI screen display at a remote terminal according to oneembodiment of the invention. In the described embodiment, the displaymodule of TKET server 102 analyzes the terminal type to select from oneof at least four different display types. For example, as is shown incolumn 1204, desktop computers and laptop computers receive a set ofdisplay signals for generating a “full” GUI screen display. In otherwords, a fully defined GUI screen display is generated at the remoteterminal responsive to a set of signals that cause such a display beingreceived by the remote terminal and transmitted by the TKET server.Column 1208, however, illustrates a reduced set of display signals thatmight be transmitted to what is being referred to herein as a minilaptop. A mini laptop, as defined herein, is a device that, in terms ofdata storage and processing capacity, is somewhere between a PDA such asa Palm Pilot® and a laptop computer. Many companies are now starting toproduce very powerful PDA's that contain or communication transceiverscapable of supporting reasonably high data throughput rates internalmodems but that do not provide the power and speed of a modern laptop.

Column 1212 illustrates that for certain types of terminals, such as aPDA, a minimal set of display signals are to be transmitted therebyresulting in the user terminal displaying a minimal GUI screen display.For example, if the user terminal is a wireless PDA, then a set ofdisplay signals that would generate a minimal GUI screen display aretransmitted by the display module of the TKET server. Finally, if theterminal is merely a telephone having a very limited display capacity,as is shown in column 1216, the display signals may comprise little morethan text and control signals for the text. Alternatively, if the userterminal is a telephonic device, the “display signals” may comprisenothing more than voice information generated by an IVR. Alternatively,the display signals for phones might be a combination of text and voicesignals.

For each of these types of devices, there are multiple ways that thedisplay module and/or other modules within the TKET server 102, of FIG.1 for example, may determine the type of user terminal. The protocolbeing used by the terminal in establishing a communication link with theTKET server can be very revealing as to the type of terminal. Forexample, if TKET server 102 of FIG. 1 analyzes a received signal todetermine whether the remote user terminal is using an HTML, an HDML ora WAP protocol for communicating. If the terminal is using HTML, then itprobably is a device having the capability of a desktop, a laptop, orother similar computer. If the protocol is a WAP protocol, then the TKETserver may determine that the communication path includes a wirelesslink. If the protocol is an HTML protocol, the TKET server may determinethat the backup user terminal is a PDA.

FIG. 13 is a table illustrating a method for determining whether togenerate a set of signals for displaying either a full, reduced orminimal GUI screen display based upon communication path characteristicsaccording to one aspect of the present invention. Referring now to theexemplary system described FIG. 13, it is seen that one of at leastthree different display modes of full, reduced and minimal areillustrated in columns 1304, 1308 and 1312, respectively. It should beunderstand the invention includes having different numbers of displaynodes. Additionally, rows 1316, 1320 and 1324 illustrate differentcommunication path characteristics that influence the display mode ortype of GUI screen display screen that is generated by the TKET server.

Examining row 1316, if the communication link is an integrated servicesdigital network (ISDN), a T1, a new generation wireless (for example,3G) communication link or if the communication link is transceived by amodem having a modem bit rate that equals or exceeds 56K, then the TKETserver generates a full GUI screen display. Alternatively, if the userterminal modem is slower than a 56K modem or a wireless communicationlink that is older than a 3G wireless communication link, then the TKETserver generates a reduced GUI screen display. Alternatively, if thewireless communication link includes transmission from a satellitesystem, the known latencies associated with satellite transmissionsprompts the TKET server to transmit a minimal set of display signalsthat will prompt the receiving user terminal to generate a minimal GUIscreen display. Similarly, if the wireless communication link suggeststhat a limited bandwidth channel is to be used, such as those channelsfor wireless PDAs and cellular phones, then a minimal GUI screen iscreated for transmission to the user terminal.

Referring now to row 1320, it may be seen that the number of gatewayscan also influence whether a full, reduced or minimal set of displaysignals are transmitted for the generation of the GUI screen displayscreen. In one embodiment of the present invention, if the displaysignals have a communication path that includes only a number ofgateways that is less than a defined number “A”, then a full GUI screendisplay is transmitted unless there is a different reason for reducingthe magnitude of the GUI screen display screen. However, if the numberof gateways is within a range, by way of example, between the numbers Aand B, then a reduced set of signals are transmitted to create a reducedGUI screen display. Finally, if the number of gateways exceeds thenumber B, then a minimal set of display signals are transmitted tocreate a minimal GUI screen display. In one described embodiment, “A” isset equal to two and “B” is set equal to three. Accordingly, if thereare one or less gateways, a full GUI screen is created (assuming allother conditions are satisfied for creating a full screen). If thecommunication link includes two or three gateways, then a reduced GUIscreen is created. Otherwise, in the described embodiment, a minimalscreen is created.

Row 1324 illustrates that geography may also be used to determinewhether to transmit a full, reduced or minimal set of display signals tocreate corresponding GUI screen display screens. For example, if thedisplay signals are being transmitted through the various networks to ageographic location that is within the North American continent, then afull set of display signals are transmitted. If, on the other hand, thesignals are being transmitted either to Central America, South Americaor Europe, then a reduced set of display signals are transmitted tocreate a reduced GUI screen display screen. Finally, for all otherlocations, by way of example, the Far East, the Middle East or Australiaor New Zealand, then a minimal set of display signals to create aminimal GUI screen display screen are transmitted. In summary,therefore, the table of FIG. 13 illustrates that the type ofcommunication networks, the number of gateways, and the geographiclocation of the receiver or user are all significant parameters indetermining whether to transmit a full, reduced or minimal set ofdisplay signals to create the corresponding full, reduced or minimal GUIscreen display screens in a preferred embodiment of the invention.

FIG. 14 is a functional block diagram illustrating the circuitry withina time keeping and expense entry server according to one embodiment ofthe present invention. As may be seen, a TKET server 1400 includes aprocessor 1404, a memory 1408, a temporary memory 1412, and a buscontroller 1416, each of which is connected to a bus 1420. Memory 1408is formed of a hard drive while temporary memory 1412 is formed ofrandom access memory. In general, memory 1408 is for storing computerinstructions that define the operational logic of the server 1400 asdescribed herein this application with particular reference to theillustrated methods and processors. Thus, processor 1404 receives thecomputer instructions by way of bus 1420 and executes them. Theprocessor, as needed, temporarily stores data, by way of bus 1420,within temporary memory 1412. The processor may be any known type ofprocessor. While the permanent memory in the described embodiment is ahard drive, any type of memory capable of retaining information throughpower cycles may be used. As may also be seen, a network interface 1424is connected to the controller 1416 to enable the server 1400 tocommunicate with other external devices.

The modules described in this application are formed logically by theprocessor's execution of the stored computer instructions. The serverand/or modules may, in alternate embodiments, be implemented byapplication specific integrated circuits or other known circuit designapproaches made to implement a specified logic design.

The invention disclosed herein is susceptible to various modificationsand alternative forms. Specific embodiments therefor have been shown byway of example in the drawings and detailed description. It should beunderstood, however, that the drawings and detailed description. Itshould be understood, however, that the drawings and detaileddescription thereto are not intended to limit the invention to theparticular form disclosed, but on the contrary, the invention is tocover all modifications, equivalents and alternatives falling within thespirit and scope of the present invention as defined by the claims.

What is claimed is:
 1. A time keeping and expense tracking servercomprising: a processor; memory coupled to the processor; and the memorystoring a plurality of computer instructions for execution by theprocessor for creating a graphical user interface (GUI) screen,comprising: a plurality of instructions that, upon execution by theprocessor, cause the processor to analyze a user terminal capacityincluding at least one of terminal type, terminal graphics capability;determining an appropriate communication protocol according to terminaltype; a plurality of instructions that, upon execution by the processor,cause the processor to analyze a communication channel throughputcapacity including determining a type of communication link furtherincluding determining whether the communication is one of a broadband,wireless or dial-up communication link; a plurality of instructionsthat, upon execution by the processor, cause the processor to analyzeuser defined GUI screen page parameters; and a plurality of instructionsthat, upon execution by the processor, cause the processor to build aGUI screen according to at least one of terminal type, terminal graphicscapability, communication protocol, and type of communication link. 2.The time entry and expense tracking server of claim 1 wherein thecommunication link is one of a high speed serial digital link.
 3. Theserver of claim 2 further including logic to generate GUI screens whosefeatures are determined also by user selection.
 4. The server of claim 3wherein user selection is determined by the universal resource locator(URL) used as an Internet address for accessing the system.
 5. Theserver of claim 3 wherein user selection is determined by user responseto a prompt provided by the system.
 6. The server of claim 1 wherein theserver determines a throughput capacity of a slowest data link betweenthe user terminal and the server as a part of building a GUI page. 7.The server of claim 1 wherein the protocol is a hand held device markuplanguage.
 8. The server of claim 1 wherein the protocol is a hypertextmarkup language.
 9. The server of claim 1 wherein a simpler GUI page iscreated if the terminal is a personal digital assistant (PDA).
 10. Theserver of claim 1 wherein the server evaluates user profiles that aredefined for the user as a part of creating a GUI page.
 11. The server ofclaim 1 wherein the server determines data content to be populated onthe GUI according to what GUI objects are to be displayed.
 12. A timekeeping and expense entry server, comprising: a processor; a memory forstoring computer instructions that define the operational logic of theserver; and a bus coupled to enable the processor to receive and executethe computer instructions wherein the computer instructions define logicto: enable the server to act as a time clock by receiving and storingtime entries in the form of start and stop time for a user; enable theserver to communicate through a plurality of networks by storing aplurality of communication protocols; and prompt the server to generateone of a plurality of GUI screens, each having different content,according to at least one of terminal type and capacity, communicationlink throughput capacity, and terminal display capacity.
 13. The serverof claim 12 wherein the computer instructions define logic forgenerating GUI display screens according to the types of networksthrough which the GUI display screens will be transmitted.
 14. Theserver of claim 12 wherein the computer instructions define logic forgenerating GUI display screens according to user terminal type.